This PR allows canisters to accept and burn cycles when executing
queries in replicated mode (e.g. as an ingress message or when another
canister calls the query method). See also spec
[PR](dfinity/portal#3760).

This allows canisters to expect some payment in cases someone is calling
an expensive endpoint similar to how this is possible in update calls.
Given that replicated queries run across all nodes, there's no technical
issue in persisting cycles changes and it gives developers another way
of protecting expensive endpoints of their canisters.

The main parts of the change are the following:

Previously the sandbox would return an optional `StateModifications`
object as changes would need to be persisted in update calls but not in
queries. Since we would like to persist cycles changes which are part of
the system state of the canister, the struct is modified to have an
`Option<ExecutionStateModifications>` to capture the optionality of
applying execution state changes while it always includes
`SystemStateChanges`. The system API is also adjusted to return only the
changes that are relevant per context of execution.

The benefit of this is that it makes more clear what parts of the
canister state can be persisted. It also allows to handle more uniformly
other parts of the system state that need to be persisted for replicated
queries, like canister logs. Instead of handling them separately, they
could now be simply included when applying changes to the system state
(not included in this PR but would be a possible follow up). Further
future changes that have similar characteristics (e.g. persisting
canister metrics in a way similar to logs) could be incorporated more
easily.

The second big chunk of changes is in the `replicated_query` execution
handler. The handler is modified to allow for handling the acceptance of
cycles and refunding any remaining amount to the caller.

Some tests were also added to confirm things work as expected.